What Is AWS Lambda?
AWS Lambda is a service for serverless computing, also known as functions as a service (FaaS). It enables users to run functions on-demand and invoke those functions manually, via cloud service events or API. With Lambda, users can access infrastructure on-demand with no need to provision resources or maintain hardware. Additionally, Lambda charges users for the computation power used with no additional responsibilities.
Common use cases for Lambda include:
- Real-time data processing
- Extract, transform, load (ETL) processes
- Application, website, and Internet of Things (IoT) backends
How Does AWS Lambda Work?
In Lambda, you create functions in the language of your choice. The service natively supports the most common languages and supplies a Runtime API for integrating any non-native languages, frameworks, or libraries. Once your function is ready, it is packaged along with configuration and resource requirement information. This package is then triggered as needed.
When Lambda functions are called, each runs in an individual container that operates on a multi-tenant cluster of machines maintained by AWS. This enables you to run multiple instances of a single function concurrently. It also enables you to run several different functions at once.
When using Lambda functions you are not responsible for any infrastructure maintenance or management. You have control over your individual functions and triggers as well as allocated computational power, bandwidth, and I/O.
AWS Lambda Challenges and Solutions
Lambda can provide an excellent solution for your serverless needs but the service is not without its challenges. Below are some of the most common challenges you may face and some solutions you can apply.
Improving Cold Start Performance
Cold starts are caused when a new container instance has to be created for a function to run. This happens when there are long weight periods between function executions, causing containers to be killed. Maintaining active container instances for every possible function is not resource-efficient for AWS so only those functions that are active are kept live.
Improving Lambda cold start performance is something you can do with the help of third-party tools and a few modifications to your practices. For example, writing functions in faster loading languages to reduce start times. However, your best option is to try to reduce the frequency of your cold starts.
One way to reduce frequency is by scheduling ping events to your functions. This ensures that a function is reactivated before hitting the idle limit (around 30 minutes). However, when doing this, be careful not to ping your function too often. Doing so can delay function execution times, negating the performance gained by keeping functions alive.
Monitoring and Logging
Like all services and implementations, you need to be able to monitor your Lambda functions to ensure that you are getting the performance you need. Without monitoring it is difficult or impossible to determine if functions are triggered as you want. It is also a challenge to determine if your resource requirements are properly defined. However, with Lambda, you cannot rely on persistent logs or monitoring agents as you can with instances.
Instead, you need to rely on the metrics and logs sent to AWS CloudWatch. This service collects performance and runtime data that you can access directly or ingest with third-party solutions. You can also use the X-Ray service for application tracing. In combination, these services should help you identify most issues.
Debugging
If your functions are not operating as expected, debugging isn’t always straightforward. For example, reviewing logs from CloudWatch can be challenging if you need to view logs from multiple executions in a time-ordered way. Additionally, the distributed nature of serverless architectures and services can make it difficult to identify where problems originate from.
One way to address these issues is to ensure that you properly debug your functions before uploading to Lambda. This helps ensure that it is not the function itself that is the problem. It can also help you narrow down if any associated services are the issue.
You can do this debugging with your default tools or you can use the debug mode that is available in the AWS Serverless Application Model (SAM) CLI. You are also able to run SAM locally or as an integration with your integrated development environment (IDE) via a toolkit. Toolkits are available for JetBrains, PyCharm, IntelliJ, and Visual Studio Code IDEs.
Avoiding Timeouts
Lambda timeout values determine how long a function can run before it is terminated by the service. These values prevent functions from running longer than expected or indefinitely due to faulty logic or response issues. The maximum time that Lambda functions can run is five minutes. Anything longer than that defeats the purpose and cost savings of FaaS.
In addition to issues related to function size or complexity, there are several other timeouts that you may encounter issues within Lambda functions. These include:
- Amazon API gateway-related timeouts—has a limit of 29 seconds for integration timeout. This limit applies to all integrations, including Lambda, HTTP, AWS services, and proxies. If you are frequently seeing API related timeouts you should check for bottlenecks downstream.
- Low memory-related timeouts—when you create functions you specify the resource requirements. If the requirements you define are too low for your actual needs, your functions may timeout. You can check if low memory is the cause of your timeouts by checking the
MemorySetInMBandMemoryUsedInMBvalues in your logs. If these values are frequently close or the use-value is higher, consider increasing your memory requirements defined in the function. - Virtual private cloud (VPC)-related timeouts—attempting to run Lambda functions that connect to external services in VPCs should be avoided. This is because requests cannot be routed through to the Internet, resulting in no response. While there are workarounds for this, it requires advanced networking skills and is often not worth the additional effort it takes to set connections up.
Conclusion
As a serverless service, Lambda does eliminate the need to spend time and resources on provisioning and hardware. However, it still requires work to troubleshoot performance issues. Perhaps the most known issue is Lambda cold start performance, which can be difficult to optimize and troubleshoot, but it is possible to achieve good results by pinging functions and integrating with third-parties.
You should also take care to avoid timeouts, which may result due to function size limitations, API misconfigurations, low memory, and VPC. If you set up an efficient monitoring and logging cycle, you can keep track of function performance issues and apply fixes on time. But, since Lambda debugging can be complex, your best course of action is perhaps prevention. So make sure your initial configurations are solid, and monitor for specific issues. Monitoring for common issues could save you a lot of time on investigating the source of the problem.
